Technical architecture is one of several architecture domains that form the pillars of an enterprise architecture or solution architecture. It describes the structure and behaviour of the technology infrastructure of an enterprise, solution or system. It covers the client and server nodes of the hardware configuration, the infrastructure applications that run on them, the infrastructure services they offer to applications, the protocols and networks that connect applications and nodes. It addresses issues such as performance and resilience, storage and backup.
Although technical architecture is sometimes used as a synonym of system architecture, they are actually different architecture domains. While system architecture, applied specifically within the context of information systems, encompasses both the application architecture and data assets, and their logical interrelations to the business processes they support; the technical architecture describes in detail the software and hardware capabilities to fully enable such application and data services.[1]
Alternatively, technical architecture is considered part of software architecture. The remainder of this entry takes this last view point.
Contents |
Technical architecture is a part of software architecture, which focuses on how to deal with certain aspects of the software engineering process. It allows us to design better systems by:
The following steps may be involved in the discipline of technical architecture:
There are two important processes defined in technical architecture. These processes will be clarified in the underlying text.
Technical Process is to be defined unambiguously. The main deliverable for a software architect is the architecture documentation, motivating and describing the structure of the system through various views. However, though system structuring forms a basis for the architectural design process, it is just one of several activities critical to the creation of a good architecture. In order to make such a deliverable to be able to instruct software developers, the following model can be used.
First architectural requirements are needed to focus the structuring activities. These requirements are then input to produce Architecture specifications. At the end, a validation phase provides early indicators and opportunities to resolve problems with the architecture. The model contains an iterative part, indicating that the Architecture validation can be input for new requirements.
Architectural requirements are a subset of the system requirements, determined by architectural relevance. The business objectives for the system, and the architecture in particular, are important to ensure that the architecture is aligned with the business agenda. The system context helps determine what is in scope and what is out of scope, what the system interface is, and what factors impinge on the architecture. The system value proposition helps establish how the system will fit the users’ agenda and top-level, high-priority goals. These goals are translated into a set of use cases, which are used to document functional requirements. The system structure fails if it does not support the services or functionality that users value, or if the qualities associated with this functionality inhibit user performance or are otherwise unsatisfactory. System qualities that have architectural significance (e.g., performance and security, but not usability at the user interface level) are therefore also important in directing architectural choices during structuring.
Requirements may already have been collected by product teams. In that case, the architecture team needs to review those requirements for architectural relevance and completeness (especially with respect to non-functional requirements), and be concerned with requirements for future products that the architecture will need to support.
For the architecture of a product line or family, architectural requirements that are unique to each product and those that are common across the product set need to be distinguished so that the structure can be designed to support both the commonality and the uniqueness in each product.
The architecture is created and documented in the system structuring phase. This is decomposed into sub-phases, see therefore also the software architecture views:
First, the architectural vision is formulated, to act as a beacon guiding decisions during the rest of system structuring. It is a good practice to explicitly allocate time for research in documented architectural styles, patterns, dominant designs and reference architectures, other architectures your organization, competitors, partners, or suppliers have created or you find documented in the literature, etc. Based on this study, and your and the team’s past experience, the meta-architecture is formulated. This includes the architectural style, concepts, mechanisms and principles that will guide the architecture team during the next steps of structuring.
The system is decomposed into components and the responsibilities of each component, and interconnections between components are identified. The intent of the conceptual architecture is to direct attention at an appropriate decomposition of the system, and on what the system does or will do, without delving into how it does it (such as the details of interface specification and type information). Moreover, it provides a useful vehicle for communicating the architecture to non-technical audiences, such as management, marketing, and many users.
The conceptual architecture forms the starting point for the logical architecture, and is likely to be modified as well as refined during the course of the creation of the logical architecture. Modeling the dynamic behavior of the system at the architectural level is a useful way to think through and refine the responsibilities and interfaces of the components. Component specifications including the following make the architecture concrete.
An execution architecture is created for distributed or concurrent systems. It is formed by mapping the components onto the processes of the physical system. Different possible configurations are evaluated against requirements such as performance and scaling.
At each step in structuring, it is worthwhile challenging the team’s creativity to expand the solution set under consideration, and then evaluating the different architecture alternatives against the prioritized architectural requirements. This is known as architecture tradeoff analysis, and it recognizes that different approaches yield differing degrees of fit to the requirements. Selection of the best solution generally involves some compromise, but it is best to make this explicit.
During structuring, the architects obviously make their best effort to meet the requirements on the architecture. The architecture validation phase involves additional people from outside the architectural design team to help provide an objective assessment of the architecture. In addition to enhancing confidence that the architecture will meet the demands placed on it, including the right participants in this phase can help create buy-in to the architecture. Architecture assessment involves "thought experiments", modeling and walking-through scenarios that exemplify requirements, as well as assessment by experts who look for gaps and weaknesses in the architecture based on their experience.[2] [3]
Another important part of validation is the development of prototypes or proofs-of-concept. Taking a skeletal version of the architecture all the way through to implementation, for example, is a really good way to prove out aspects of the architecture. Some systems may require a horizontal prototype to showcase the range of functions, while others need the clarification that a vertical prototype can bring.
Architecture projects are susceptible to three major organizational sources of failure:
The organizational process helps address these pitfalls. Two phases—namely Init/Commit and Deployment—bookend the technical process. However, the principal activities in these phases, namely championing the architecture and leading/teaming in Init/Commit, and consulting in Deployment, also overlap with the technical process activities.
The Initiate phase focuses on initiating the architecture project on a sound footing, and gaining strong commitment from upper management. The creation of the architecture vision is central both to aligning the architecture team and gaining management sponsorship. A communication plan is also helpful in sensitizing the team to the need for frequent communication with others in the organization. A heads-down, hidden skunkworks architecture project may make quick progress—as long as it is well-led and its members act as a team. However, not listening to the needs of the management, developers, marketing, manufacturing and user communities and not paying attention to gaining and sustaining sponsorship in the management and technical leadership of the organization, or buy-in from the developer community, will lead to failure. The communication plan places attention on balancing the need for communication and isolation, as well as planning what to communicate when, and to whom.
The Deployment phase follows the technical process, and addresses the needs of the developers who are meant to use the architecture to design and implement products. These range from understanding the architecture and its rationale, to responding to the need for changes to the architecture. This entails consulting, and perhaps tutorials and demos, as well as the architects' involvement in design reviews.
It is important that at least the senior architect and the architecture project manager (if there is one) champion the architecture and gain the support of all levels of management affected by the architecture. Championing the architecture starts early, and continues throughout the life of the architecture, though attention to championing tapers off as the architecture comes to be embraced by the management and developer communities.
For the architecture team to be successful, there must be a leader and the team members must collaborate to bring their creativity and experience to bear on creating an architecture that will best serve the organization. This would seem so obvious as to not warrant being said, but unfortunately this is easier said than done. Explicit attention to developing the designated lead architect’s leadership skills, in the same way one would attend to developing these skills in management, is a worthy investment. Likewise, investing in activities aimed at developing the team as a team also has great payoff in the team’s efficacy.
Consulting with and assisting the developer community in their use of the architecture is important in facilitating its successful adoption and appropriate use. These activities are most intense during deployment. However, earlier communication and consulting helps create buy-in from the developer community through participation and understanding. This allows the architecture team to understand the developers’ needs and the developers to understand the architecture (and its rationale) as it evolves through the cycles of the technical process.